Do Agile Methods Marginalize Problem Solvers?

I saac Newton would have been a failure as an agile programmer. Instead of sharing his work, New-ton rarely communicated with other workers and hid his results from them for fear they would steal his work. Instead of collaborating, he quarreled with coworkers, particularly Robert Hooke and Gottfried Leibniz, over credit for his discoveries (James Gleick, Isaac Newton, Pantheon, 2003). Newton's vendetta against Leibniz did not stop at taking credit for inventing calculus—it verged on character assassination. Embodying the antithesis of the people-oriented programming style, Newton would certainly disrupt any agile programming team. Yet his accomplishments should make any programming manager think twice about not using a person of his skills. Thomas Aquinas also would have failed as an agile programmer. His perpetual silence earned him the nickname, " Dumb Ox. " A fellow student assumed that Aquinas refrained from participating in class discussions because he did not understand the material. This well-meaning student offered to tutor Aquinas. Things went smoothly until the student came to a question he didn't know the answer to—and found to his surprise that Aquinas did. In a programming group, Aquinas would probably be the proverbial programmer who sits silently and walks through his code all day. Like Aquinas's fellow student, the other programmers would assume that a lack of ability led to his nonparticipa-tion in group discussions. Thus, Aquinas would be given unimportant tasks and ignored. A software development methodology should take advantage of pro-grammers' strengths and avoid their weaknesses. It seems that agile methods would do exactly the opposite for the greatest mathematician of the Enlightenment and the greatest logician of the Middle Ages. This inability to adapt to the working styles of Newton and Aquinas should raise doubts about the efficacy of agile methods. Currently, many different agile methodologies have become popular. However, all advocate the same basic principles: • Individuals and interactions over processes and tools. To implement this principle, the organization moves programmers out of their offices and cubicles into open-floorplan offices. This minimizes privacy so that programmers can see and hear what everyone else is doing. • Working software over comprehensive documentation. The project leadership discourages programmers from writing documentation and encourages them to produce software instead. • Customer collaboration over contract negotiation. The developers demonstrate the prototype software to their customers with the expectation that the customers will provide them with useful feedback. • Responding to change over …